1 A METHOD OF FAST FINGERPRINT SEARCH SPACE PARTITIONING AND 

2 PRESCREENING 

3 BACKGROUND OF THE INVENTION 

4 1. Field of the Invention 

5 This invention generally relates to fingerprint matching systems in which a fingerprint is matched 

6 to reference fingerprints in a database, and more particularly, to a fingerprint matching system 

7 for rapidly locating matching fingerprints in a repository of fingerprint data containing a million or 

8 more fingerprints by pre-screening the repository of fingerprint data for likely matching 

9 fingerprints to create an index or list of candidate mated fingerprints. 

10 2. Background of the Invention 

Ifc Pattern matching or comparison schemes have many applications such as the matching of 

tl fingerprints for comparison with file fingerprints. Fingerprints are very rich in information content 

M and basically contain two major types of information: 1) the ridge flow information, and 2) the 

1M specific features or minutiae (minutia) of the fingerprint. As used herein , the fingerprint to be 

liil 

1§ identified may be termed an "unknown" fingerprint or a "latent" fingerprint. 

M Fingerprints uniquely identify an individual based on their information content. Information is 

represented in a fingerprint by the minutia and their relative topological relationships. The 

l8j number of minutia in a fingerprint varies from one finger to another, but, on average, there are 

iS about eighty (80) to one hundred and fifty (150) minutia per fingerprint. In the fingerprint context, 

20 a large store of fingerprints exists in law enforcement offices around the country. These 

21 fingerprints include files of fingerprints of known individuals, made in conjunction with their 

22 apprehension or for some other reason such as security clearance investigation or of obtaining 

23 immigration papers, often by rolling the inked fingers on cards, and also includes copies of 

24 latent fingerprints extracted from crime scenes by various methods. 

25 These reference fingerprints are subject to imperfections such as overinking, which tends to fill 

26 in valleys in fingerprints, and underinking, which tends to create false ridge endings, and 

27 possibly both overinking and underinking in different regions of the same fingerprint image. 

28 Smudging and smears occur at different places in the fingerprint due to unwanted movement of 

29 the finger, or uneven pressure placed on the finger, during the rolling process. The stored 

30 fingerprints are also subject to deterioration while in storage, which may occur, for instance, due 



1 to fading of the older images, or due to stains. Furthermore, the wide variation in the level of 

2 experience among fingerprint operators, and the conditions under which the fingerprint is 

3 obtained, produces wide variation in quality in the fingerprint images. Similar effects occur due 

4 to the variation of the scanning devices in cases of live scanning of fingerprints. 

5 Matching of fingerprints in most existing systems relies for the most part on comparison of cores 

6 and deltas as global registration points, which tends to make the comparisons susceptible to 

7 errors due to the many sources of distortion and variations listed above, which almost always 

8 occur due to the various different inking, storage and reprocessing conditions which may be 

9 encountered. 

10 As described at pages 164-191 of the text Advances in Fingerprint Technology, by Henry C. Lee 

1 1 and R. E. Guenssten, published by Elsevier in 1991, efforts have been underway for a long time 
X% to automate fingerprint identification, because manual search is no longer feasible due to the 
li® large number of reference files. The effort to automate fingerprint identification involves two 

ljjfj distinct areas, namely (a) that of fingerprint scanning and minutia identification, and (b) 

US comparison of lists of minutia relating to different fingerprints in order to identify those which 

\:M match. Large files of reference fingerprints have been scanned, and minutia lists in digital form 

la 

¥1 obtained therefrom, either by wholly automated equipment, or with semi-automated equipment 

ljfj requiring human aid. While not all problems in scanning of fingerprints and detection of minutia 

lP have been solved, it appears that the matching problem is the more pressing at this time. 

M 

M The matching or search subsystem constitutes the most critical component of any Automated 

21 Fingerprint Identification System (AFIS). Its performance establishes the overall system 

22 matching reliability (the probability of declaring the correct mate, if one exists in the database), 

23 match selectivity (the average number of false candidates declared in each search attempt), 

24 and throughput, which is particularly important in large database systems. The unique 

25 identification of fingerprints is usually performed using the set of minutia contained in each 

26 fingerprint. 

27 U.S. Pat. No. 5,613,014, issued Mar. 18, 1997 in the name of Eshera et al. describes a 

28 fingerprint matching technique using a graphical attribute relational graph (ARG) approach. This 

29 ARG approach is fast, and particularly advantageous for those cases in which the minutia of the 

30 latent or unknown fingerprint are numerous and well defined, but may be hindered in finding the 
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1 correct match by errors in locating minutia near the center of each star when the latent image is 

2 poor and minutia are missing. 

3 However, because the fingertip skin is flexible, the relative locations and orientation of the 

4 pattern singularities and minutiae differ (at least slightly) from one impression of a given finger to 

5 the next under controlled conditions (for example from multiple rolled prints of the same finger). 

6 These differences are magnified in latent, unknown fingerprints which are not made with the 

7 assistance of a fingerprint operator, but rather may be left a crime scene on different types of 

8 surfaces, such as flexible surfaces, under vastly differing pressures, with some times only a 

9 fraction of the finger area being involved. This invention addresses the problem of identifying 

10 candidate mate fingerprints in a repository for either rolled or latent search fingerprints. 

11 SUMMARY OF THE INVENTION 

iM Accordingly, it is an object of the present invention to overcome the deficiencies of the prior art 

lfll in addressing the problem of identifying candidate mate fingerprints in a repository for either 

ljtj rolled or latent search fingerprints. 

ki Yet another object of the present invention is to provide a method for fast fingerprint 
identification which rapidly locates matching fingerprints in a repository of fingerprint data 

111 containing a million or more fingerprints. 

i 

f 81 Yet another object of the present invention is to provide a method of fingerprint identification 

|2 whereby a large repository of fingerprints is very rapidly searched for members of the repository 

20 that most nearly match the search print to create a list of candidate mate fingerprints that are 

21 then more carefully search for matching features. 

22 Still another object of the present invention is to provide a method of fast fingerprint 

23 identification wherein the index is based on each minutia and selected neighbors of each 

24 minutia in each file fingerprint in the repository and then the index is subsequently searched to 

25 identify all minutiae which correspond to the minutiae in a search fingerprint. The results of this 

26 search are analyzed to determine which file fingerprints contributed the most minutiae with the 

27 best correspondence to the minutiae in the search fingerprint. 

28 These and other objects, advantages and features of the present invention are achieved by a 

29 method comprising the steps of: inputting the contents of a fingerprint repository comprising file 

30 fingerprints for index creation; creating an index based on each minutia and selected neighbors 
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1 of each minutia in each file fingerprint in the repository; searching the index to identify all 

2 minutiae which correspond to the minutiae in a search fingerprint; and analyzing results of this 

3 search to determine which file fingerprints contributed the most minutiae with the best 

4 correspondence to the minutiae in the search fingerprint. 

5 BRIEF DESCRIPTION OF THE DRAWINGS 

6 Figure 1 is a block diagram representing repository index data; 

7 Figure 2 is a block diagram illustrating the steps for generating an index of fingerprint files from 

8 the repository; 

9 Figure 3 is a block diagram illustrating the steps of the Createlndexfiles subroutine for creating 

1 0 each of the files of the a specific index; 

=3 

Uj Figure 4 illustrates the data contained in a hash list node; 

iy 

M Figures 5 and 6 illustrate the steps of the ExactMatch subprogram; 

;jrj 

T. i 

111 

Figure 7 illustrate the steps of the AddSubject subprogram; 

M Figure 8 illustrates the steps of the GenerateHashCode subprogram; 

ifl 

o 

1=5 Figure 9 illustrates a typical quantization vector; 

; : *J 

1k? Figure 10 illustrates a typical equalization vector; 

17 Figure 1 1 illustrates a typical equalization matrix; 

1 8 Figure 1 2 illustrates the steps of the AddSubjectToList program; 

19 Figures 13 illustrate the steps of the Searchlndex program; 

20 Figures 14-15 illustrate the steps of the IndexSearch subprogram; 

21 Figure 16 illustrates the steps of the VisitMatch subprogram; 

22 Figure 1 7 illustrates transfer vector data; 

23 Figure 18 illustrates match data; 
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1 Figure 19 illustrates the steps of the AccumulateHough subprogram; and 

2 Figures 20 and 21 illustrate the steps of the EvaluateMatch subprogram. 

3 DETAILED DESCRIPTION OF THE PREFERED EMBODIMENT(S) 

4 The following terms used in this disclosure are defined as set forth below. 

5 Fingerprint characteristics - Data describing a fingerprint that has been automatically or 

6 manually extracted from an image of the fingerprint. This data includes but is not limited to the 

7 Pattern Classification and a set of Fingerprint Minutiae (typically 10 to 200). 

8 Fingerprint Repository - One or more files containing the characteristics of multiple fingerprints. 

Fingerprint Minutiae - Endings or Bifurcations in the friction ridges of a fingerprint. Also known 

IS as Galton points or Level 2 details. 

O Pattern Classification - Enumeration of the general patterns of the flow of the friction ridges of a 

10 fingerprint, the most common being arches, loops and whorls. Also known as Level 1 details. 

§ ; i 

f3 Minutia Data - Data describing the position, type, and orientation of a given minutia, and the 

B relationship of that minutia to its neighboring minutiae. 

I;J Pattern Singularities - Discontinuities in the general flow of the friction ridges of a fingerprint, the 

11 most common being cores and deltas. The number, types and relative locations of the Pattern 
Xl Singularities determine the Pattern Classification. 

18 File Print - A fingerprint whose characteristics have been stored in a repository. 

1 9 Search Print - A fingerprint that is being sought in the repository. 

20 Mate (Print) - The File Print (or prints) which correspond to the subject (person) who generated 

21 the Search Print. 

22 Rolled Print - A fingerprint obtained by rolling the subject finger across the acquisition surface. 

23 File prints are almost exclusively rolled prints. Search prints may or may note be rolled prints. 

24 Latent Print - A fingerprint impression left at the scene of a crime or developed into an image by 

25 investigators. 



5 



1 In accordance with the teachings of the present invention, there is provided a method for rapidly 

2 locating matching fingerprints in a repository of fingerprint data containing a large number of 

3 fingerprints wherein the method creates an index into the repository which is based on each 

4 minutia and selected neighbors of each minutia in each file fingerprint in the repository. The 

5 index is subsequently searched to identify all minutiae that correspond to the minutiae in a 

6 search fingerprint. The results of this search are analyzed to determine which file fingerprints 

7 contributed the most minutiae with the best correspondence to the minutiae in the search 

8 fingerprint. 

9 The input data for the creation of the index are the contents of a fingerprint repository (or any 

10 fingerprints that are to be added to an existing repository), or a set of characterized search 

1 1 fingerprints. For each fingerprint (either file or search) processed according to one embodiment 

12 of the method of the present invention, the following data are used: 

l|j ❖ The number of minutiae in the fingerprint. 

ni 

1^ ❖ For each minutia: 

a ; ! 

■ The base angle of the minutia in a frame of reference whose angular orientation to 
and permissible deviation from the axis of the finger is pre-defined by customer 

1|5 specification. 

^ ' The Cartesian coordinates (X, Y) of the minutia relative to the same frame of 

lf£ reference. 

20 ■ The minutia index of the nearest neighboring minutia (if any) in each of eight octants 

21 (45 degree wedges), the first octant of which is centered on the base angle of the 

22 minutia. (These minutiae are known as "octant neighbors"). Note that minutiae 

23 which fall near the edge of the fingerprint may not have neighbors in all octants. 

24 ■ The count of friction ridges between the minutia and each of its eight octant 

25 neighbors. 

26 ■ The Euclidean distance between the minutia and each of its eight octant neighbors. 

27 ■ The difference between the base angle of the minutia and the base angle of each of 

28 its eight octant neighbors. 
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1 It should be noted that the above example describes the implementation based on ARG data 

2 used in the patented LMIS ARG Matcher as disclosed by U.S. Patent No. 5,613,014, issued 

3 March 18, 1997, the entire disclosure of which is herein incorporated by reference. Other 

4 implementations, which are envisioned to be within the scope of the present invention, may use 

5 additional (or different) data and still work as well or better than the currently described 

6 embodiment. For example, high-resolution direction-to-the-octant-neighbor can be included to 

7 improve the speed, reliability and selectivity of the algorithm, providing those data are available 

8 in the repository. However, it should be noted that a primary feature of the method of the 

9 present invention is that data for neighboring minutiae are used in the index. 

10 Each minutia in the repository, and in any fingerprint that is added to the repository, is uniquely 

1 1 identified by a repository index, shown in Figure 1, which contains the following information: 

1| • The index of the subject in the repository (typically starting at zero and 

■'id 

l§ increasing by one as each subject is added to the repository). 

'i y 

|| • The index of the finger within the subject (typically starting at zero for the right 

|$ thumb and continuing through 9 for the left little finger). 

14 • The index of the minutia within the subject and finger (typically starting at 

K7 zero and increasing by one until the maximum number of minutiae allowed in 

Q the repository is reached). 

t9 In accordance with the teachings of the present invention, the method creates the data files 

20 associated with the index and adds from one to all of the fingerprints in the repository to the 

21 index. Referring to Figures 2, in step 1, the repository file(s) in the repository R are opened for 

22 read-only access. In step 2, a determination is made as to whether or not index files exist. In 

23 step 2A, if the index files do not already exist, the subprogram CreatelndexFiles, as will be more 

24 fully described with respect to Figure 3, creates the index files and opens them for read-write 

25 access. Otherwise, in step 2b the files of the existing index are opened for read-write access. A 

26 user-specified set of repository subjects can also be added manually to the index, in accordance 

27 with known methods, for example, without limitation, using records in control files, or fields in a 

28 graphic user interface or the like. 

29 In step 3, for each subject S in the repository of fingerprint files to be added to the index, 

30 Subprogram ExactMatch is used to determine whether subject S is already in the index. This is 
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1 done to avoid introducing duplicate records in the index, since the presence of duplicate records 

2 would bias the search results towards the selection of those subjects duplicated in the index. 

3 In step 3a, if the subject S is not already in the index, subprogram AddSubject is used to add 

4 subject S to the index. In step 4, once all subjects S in the repository have been scanned and 

5 the non-duplicative subjects have been added to the index, the repository and index files are 

6 closed. 

7 Figure 3 illustrates the individual steps of the CreatelndexFiles subprogram used to create the 

8 all the files needed for a specific index I. In this regard, it is important to note that an index can 

9 be created for any subset of ten fingers. Typically, the two index fingers are used for rolled 

10 search capability, however, all ten fingers is needed for latent search capability where the 

1 1 source finger number is unknown. In step Step 2(a)1 of the CreatelndexFiles subroutine, index 
S| neighborhood combinations are created for each finger of the index. Neighbor combinations are 
I| based on selecting 2 of eight octant neighbors to produce 28 possible combinations per finger, 
m as shown in Tablel. In one embodiment of this subprogram of the present invention, all 

combinations of two neighbors (N=2) out of 8 neighbors are used, however N may be 1, 2, 3, 4, 

f{j 5, 6 or 7. For the available LMIS ARG data, N=2 is the best, but N=3 has potential value for 

17 other fingerprint data, for example, when there is no ridge count data, in which case N=3 is 

|| better than N=2. 
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1 Table 1 . All combinations of two neighbors out of eight neighbors. 

2 In step 2(a)2, one Hash Table file T is created for each Finger/Neighbor Combination. A hash 

3 table consists of 32,768 entries, each of which contains the following data: 

4 ❖ The index of a hash list node in the hash list file. 

A ❖ The number of hash list nodes associated with the hash code 

tjj There are 56 Hash Table files T[2][28]. In this regard, the 32,768 entries are based on a 15-bit 

:t[ hash code. This is probably the smallest practical hash code for fingerprint applications and is 

;S based on the LMIS ARG data. If other data were available, the number could increase to more 

^ * i 

;2 than 4 million, which would give better performance. The data elements of an entry are 

10 independent of the number of entries (they would still be a hash list node index and a hash list 

?! "1 

tt node count). 

EST 

t% In step 2(a)3, one Hash List file L is created for each Finger/Neighbor Combination. A hash list 

lj| consists of N hash list nodes, where N is a function of the number of minutiae in the repository, 

14 plus any room needed for repository expansion. Each Hash List Node contains the following 

15 data, as shown also in Figure 4: 

16 ❖ The Hash Code associated with the buffer (needed for data reliability checking, but 

17 otherwise not used in the algorithm). 

18 ❖ The number of populated repository index (Figure 1) slots in the buffer. 

19 ❖ Thirty repository index slots. 

20 There are 56 Hash List files L[2][28]. The optimum number of slots in a node is a function of the 

21 hash code distribution that, in turn, is a function of the fingerprint characteristics in the 

22 repository. For the LMIS ARG data the absolute best is 24 slots, but 30 is nearly as good and 
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1 offers the additional benefit of producing a node size that is a power of 2 and thus much more 

2 efficient in terms of practical disk operations. 

3 In step 2(a)4, one Hash List Node Used file U is created for each Finger/Neighbor Combination. 

4 A Hash List Node Used file is a bookkeeping device which tracks which hash list nodes in the 

5 file are populated at any given time. There is exactly one bit in the Hash List Node Used file for 

6 each node in the associated Hash List file. The bit associated with a given node is set to 1 

7 when that node is in use and cleared to 0 when the node is available for use. There are 56 Hash 

8 List Node Used files U[2][28]. 

9 One embodiment of the details of step 3 shown in Figure 2 relating to the ExactMatch 

10 subprogram are shown in Figures 5 and 6. As previously noted, the ExactMatch subprogram 

1 1 determines if a specific subject S from the Repository R is already present in the Index I. This 
ltS subprogram takes advantage of the fact that a duplicate subject in the repository is, by 

i|5 definition, guaranteed to have the identical hash code and the identical repository index as one 

ljj4j already in the index. Therefore, the presence of the first existing combination associated with 

lijfj the first neighbor of the first minutiae of the first finger of the subject is indicative of a duplicate 

M while the absence is indicative that the subject is not in the index. 



21 associated with the hash code, there is no duplicate entry in the index, ExactMatch is false and 

22 the subprogram terminates. 

23 If there are hash list nodes associated with the hash code, the subprogram reads them from the 

24 disk and searches each in order until either the subject index is found or the end of the list is 

25 reached. If the subject index is found, ExactMatch is true else ExactMatch is false; in both 

26 cases, the subprogram terminates. 

27 A detail description of one embodiment of the individual process steps of the AddSubject 

28 subprogram of Step 3a of the method of the present invention are shown in Figure 7. As 

29 previously noted with particular reference to Figure 2, the AddSubject subprogram adds each 

30 existing neighbor combination of each minutia of each finger of the subject S into the index I. 




1 



m 



The first set of process steps in the embodiment of the ExactMatch subprogram shown in Figure 
5 are used to identify the first existing combination associated with the first neighbor of the first 
minutiae of the first finger of the subject. The hash code for that neighbor combination is 
calculated and used to search the appropriate hash table. If there are no hash list nodes 
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1 As seen in Figure 7, the AddSubject subprogram first selects the Finger F, Neighbor 

2 Combination C and Minutia M of each of the subject(s) being added (S). Note that F and C are 

3 used to select the appropriate Hash Table T[F][C], Hash List L[F][C] and Hash List Node Used 

4 U[F][C] files. If the Neighbor Combination C exists for Minutia M, the following steps are taken: 

5 1) Generate a hash code from the minutia and neighbor parameters and locate the hash code 

6 entry in the Hash Table T[F][C]. 2) If no prior hash list nodes are associated with the hash code, 

7 identify the next available node in the Hash List file L[F][C], store its index in T[F][C] and update 

8 U[F][C] appropriately. If prior hash list nodes are associated with the hash code, read them into 

9 memory and 3) Invoke AddSubjectToList to insert the subject (S) repository index into the first 

10 available slot in the Hash List L[F][C]. 

1 1 The steps of one embodiment of the GenerateHashCode subprogram are shown by the flow 

12 diagram of Figure 8. The GenerateHashCode subprogram produces a 15-bit hash code from 
i| the parameters of a specified Minutia M and neighbor combination C. The neighbors in the flow 
]j! diagram and this section are labeled Neighbor A and Neighbor B. The values of A and B are 
If selected, as a function of neighbor combination C, from Table 1. The ideal hash code 
][6j generation would cause each of the 32,768 possible values to be equally likely. The algorithm 
% used here approaches, but does not meet this ideal, due primarily to the distribution of the 
f& fingerprint characteristics in the repository. 

ID 

If! The Base Angle, Euclidean Distances to neighbors A and B and the Relative Angles to 

2$ neighbors A and B of minutia M are quantized using Quantization Vectors as shown in Figure 9. 

3k The contents of the Quantization Vectors are selected based on the distribution of parameters in 

22 the repository R. Experimental evidence shows that they may be generated from a subset of R 

23 and left unchanged as R grows. 

24 It should be noted that the quantization vectors are created by analyzing, on a minutia-by- 

25 minutia basis, the difference between mated pairs of fingerprint rollings. This is done by 

26 calculating the mean and standard deviation of the difference between each parameter. The 

27 value of the mean sets the starting point of the vector. The standard deviation is used to select 

28 the quantization interval. The value of the quantization vector components could change slightly 

29 based on the characteristics of a particular set of fingerprints (i.e., if one wanted to optimize the 

30 performance on fingerprints of males vs. females) or, in the case of the base angle, on the 

3 1 definition of "oriented" fingerprints as being +/- some angle. 
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1 The Ridge Counts to neighbors A and B, and the Euclidean Distances to neighbors A and B are 

2 histogram equalized using Equalization Vectors, as shown in Figure 10. As with the contents of 

3 the Quantization Vectors, the contents of the Equalization Vectors are selected based on the 

4 distribution of parameters in the repository R. Experimental evidence shows that they may be 

5 generated from a subset of R and left unchanged as R grows. The Equalization Vectors and 

6 Matrices are important only in the sense that they reduce the size of the hash code (i.e., 15 bits 

7 compared to say 20 bits) without significant impact on performance. The reduction of the size of 

8 the hash code reduces the amount of memory needed. Were memory not an issue, the 

9 Equalization Vectors can be eliminated and the larger hash code/memory usage accepted. 

10 The Relative Angle to neighbors A and B are histogram equalized into a single value using an 

1 1 Equalization Matrix as shown in Figure 1 1 . Again, the contents of the Equalization Matrix are 

12 selected based on the distribution of parameters in the repository R. Experimental evidence 
L|| shows that they may be generated from a subset of R and left unchanged as R grows. Once all 
1JP of the parameters have been quantized and equalized, they are combined into a single hash 
lflf code as shown in Equation 1 . 

lW C h = A 0 + R 0 (Ai + R,(A 2 + R 2 (A 3 + R 3 (A4 + R 4 (A 5 ))))) 

ljTj C h is the generated Hash Code 

z : i 

12E Ao is the qunatized Base Minutia Direction 

liS Ro is the range of the Base Minutia Direction 

7$f Ai is the equalized Neighbor A Ridge Count 

21 Ri is the range of the equalized Neighbor A Ridge Count 

22 A 2 is the range of the equalized Neighbor B Ridge Count 

23 A 3 is the equalized, normalized Neighbor A Euclidean Distance 

24 R 3 is the range of the equalized normalized Neighbor A Euclidean Distance 

25 A4 is the equalized, normalized Neighbor A Euclidean Distance 

26 A 5 is the two-dimension equalized, normalized Neighbor A and Neighbor b relative Directions 

27 Equation 1. Hash Code Generation. 

28 The AddSubjectToList subprogram flow diagram is shown in Figure 12. The AddSubjectToList 

29 subprogram presumes that the hash list node data for a given hash code is resident in memory. 

12 



1 Prior to invocation, existing nodes for a given hash code must be read into memory. Prior to 

2 invocation, if there are no pre-existing nodes, the memory buffer for the first node must be 

3 cleared. Each node in the list is searched for an available slot. If an available slot is found, the 

4 subject S's repository index is inserted in the slot, the node containing the slot is written to the 

5 file and done is set true. 

6 If done is false, the implication is that all pre-existing nodes are full. In this case, a new node is 

7 appended in memory, and the subject S's repository index is inserted in the first slot. Since a 

8 node has been added, the list will no longer fit in its original location. The Hash List Node Used 

9 file U[F][C] is searched for the first available set of contiguous nodes which fit the new list size. 

10 The list data are written into these nodes. The hash table T[F][C] is updated, the previous node 

1 1 list locations are cleared and U[F][C] is updated to reflect the new node usage. 

O Once an index is created, step 5 of the method of the present invention is to locate the most 

1§ likely candidate mate(s) for search subject S in index I. Step 5 of the method of the present 

f4 invention comprises, for example, the Searchlndex program, a flow diagram of which is shown 

r, IJ 

|| in Figure 13. The Searchlndex program searches for the mates, in the index I, of each entry in a 

t'4 list of search subjects. This program includes "truth" data to allow the performance of the 

\7 IndexSearch subprogram, which implements the search process itself, to be evaluated. A list of 

II search subjects is read, the index is searched for each subject, the performance is evaluated 

If and a report generated. 

'"~~4 

|| The IndexSearch subprogram flow diagram is shown in Figures 14 and 15. The IndexSearch 

21 subprogram reads a search feature vector V, identifies all repository subjects that contain 

22 similar minutiae (candidate mates), then evaluates the candidate mates, selecting the best 

23 possible matches (if any) and appending them to the result list. After reading the search feature 

24 vector V, the subprogram searches the appropriate finger(s) F, minutiae M and neighbor 

25 combinations C. If the neighbor combination C exists for minutia M of finger F, a hash code is 

26 generated for the minutia and neighbor parameters. If the hash code entry in Hash Table 

27 T[F][C] contains list nodes, the nodes are read from the Hash List file L[F][C]. The VisitMatch 

28 subprogram is invoked for every repository index in every list node for the hash code. 

29 VisitMatch (described later) accumulates match data for every candidate mate in the search. 

30 When all of the minutiae and neighbor combinations have been processed, in step 6 of the 

31 method of the present invention, EvaluateMatch is invoked to score and rank all of the 
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1 candidate mates. EvaluateMatch (described later) generates the list of the most likely mates 

2 from all of the candidates. 



3 
4 
5 
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The VisitMatch subprogram flow diagram is shown in Figure 16. The VisitMatch subprogram is 
invoked for all candidate mates in the hash list. It is called with the repository index which 
contains the subject index S, the finger index F and the minutia index M for each candidate 

6 mate. It maintains a transfer vector, whose index is the subject index field of the repository 

7 index, that points to a candidate mate evaluation structure as shown in Figure 17. The purpose 

8 of the transfer vector is to minimize the amount of memory that must be cleared at the 

9 completion of each search. The entire transfer vector must be cleared, but only those 
MatchData entries that were used in the search need be cleared. Since the MatchData entries 

1 1 are significantly larger than the TransferVector entries, there is a net reduction in memory 

12 addresses which are cleared. 

13M Each MatchData entry consists of the following data for each finger used for the search (also 
shown in Figure 18): 

1 jjj ❖ The VisitCounter which is incremented every time a given Subject/Finger is visited. 

16^ ♦> The MinutiaBitMap which contains one bit for each expected minutia; the appropriate bit is 
l|g set when a given minutia participates in the match. The number of bits set matches the 
1 8J number of individual minutiae that participated in the match operation. 



1 C * The HoLJ 9 n Accumulator (HoughAcc) which is used to accumulate the search minutiae-file 

20 minutiae relationships via a multi-dimensional Hough Transform. 

21 ❖ The MatchScore which is used during match evaluation to provide a single number whose 

22 value is proportional to the degree of match between the search fingerprint and the file 

23 fingerprint. 

24 The VisitMatch subprogram checks the TransferVector for search subject S. If the value is zero, 

25 (meaning that the subject has not yet been processed during the current search), the 

26 DataCounter is incremented (counting the number of subjects processed) and its value is 

27 placed in TransferVectorfS] and pointer P. If the value of TransferVector[S] is non-zero, 

28 (meaning that MatchData already exists for the subject. S) the value of TransferVector[S] is 

29 placed in pointer P. Subsequent operations are performed on MatchData[P][F]. 
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1 If the bit representing minutia M is not set in the MinutiaBitMap of MatchData[P][F], it is set to 

2 indicate that minutia M has participated in the match, and AccumulateHough is invoked to 

3 calculate and accumulate Hough Transform data. The VisitCounter in MatchData is incremented 

4 to count the total number of visits to this Subject/Finger. 

5 The AccumulateHough subprogram flow diagram is shown in Figure 19. The base angle and 

6 Cartesian coordinates for the Subject S, Finger F, Minutia M are obtained from the repository. 

7 The difference in base angles between the repository and search minutiae is calculated, giving 

8 DeltaBaseAngle. The repository Cartesian coordinates are rotated through DeltaBaseAngle 

9 (using standard trigonometric rotation techniques). The difference between the search minutia's 

10 coordinates and the rotated repository minutia coordinates is calculated giving DeltaX and 

1 1 Delta Y. DeltaX and DeltaY are quantized to the range 0..7 and used to increment the Hough 

1 2 accumulator HoughAcc [DeltaX][DeltaY]. 
13 

1 |j The EvaluateMatch subprogram flow diagram is shown in Figures 20 and 21 . The MatchData 

ljrtj for each finger of each candidate subject is analyzed to create a raw score using the following 

1$J equation: RawScore=(VisitCount-MinutiaCount)*(max(HoughAcc[0..7][0..7])) 

l£i The VisitCount variable effectively counts the number of minutia matches summed over all of 

17 the participating neighbor combinations. The MinutiaCount variable effectively counts the 

1 £j number of individual minutiae matches regardless of the source neighbor combination. 

T, — t 

5 -J 

"•• i 

lg There are other possible means of calculating the raw score. The most promising of these are 

2fk similar to the above equation but which replace the maximum HoughAcc value with the 

2 1 maximum of the sum of a cross pattern or a block pattern in the Hough Accumulator as in: 

22 0 1 0 1 1 1 

23 111 111 

24 0 1 0 1 1 1 

25 where we sum the neighboring cells which are indicated by 1 's in the two pattern masks. 

26 The raw score for each finger of each candidate subject is then normalized using statistical 

27 techniques appropriate for the observed exponential distribution of the raw scores. The 

28 standard deviation of the entire set of scores for the finger is calculated. The each raw score is 
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1 then divided by the standard deviation to produce a normalized exponential score for the 

2 Subject/Finger. The normalized exponential scores for each finger of each Candidate Mate are 

3 combined to produce a multi-finger score by summation. The Candidate Mates are scanned 

4 from first to last. If the multi-finger score for a particular Candidate Mate exceeds a pre- 

5 determined threshold, that subject is appended to the result list. The result list is then sorted in 

6 descending multi-finger-score order. The value of the threshold is a function of the operating 

7 point which produces the Reliability and Selectivity desired from the search process. 

8 The output of the subprogram is a list, of Candidate Mate subjects ordered from most likely 

9 (highest score) through least likely (lowest score). 

10 Although the present invention has been described in terms of specific exemplary embodiments, 

1 1 it will be appreciated that various modifications and alterations might be made by those skilled in 

f% the art without departing from the spirit and scope of the invention as specified in the following 

m 

l| claims. 
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